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Status of This Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Abstract 


Mobile IPv6é is designed to maintain its connectivity while moving 


from one network to another. It is adopted in 3G CDMA networks as a 
way to maintain connectivity when the mobile node (MN) moves between 
access routers. However, this handover procedure requires not only 


movement detection by the MN, but also the acquisition of a new 
Care-of Address and Mobile IPv6 registration with the new care-of 
address before the traffic can be sent or received in the target 
network. During this period, packets destined for the mobile node 
may be lost, which may not be acceptable for a real-time application 
such as Voice over IP (VoIP) or video telephony. This document 
specifies fast handover methods in the 3G CDMA networks in order to 
reduce latency and packet loss during handover. 
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1. Introduction 


Mobile IPv6 [2] allows mobile nodes (MNs) to maintain persistent IP 


connectivity while the MN moves around in the IPv6 network. It is 
adopted in 3G CDMA networks for handling host-based mobility 
management [12]. During handover, however, the mobile node (MN) 


needs to switch the radio link to obtain a new Care-of Address (CoA) 
and to re-register with the home agent (HA), which may cause a 
communication disruption. This is not desirable for real-time 
applications such as VoIP and video telephony. To reduce this 
disruption time or latency, a fast handover protocol for Mobile IPv6 
[3] is proposed. RFC 4260 [7] further describes how this Mobile IPv6 
Fast Handover could be implemented on link layers conforming to the 
IEEE 802.11 suite of specifications. However, 3G CDMA and IEEE 
802.11 networks are substantially different in the radio access, the 
representations of the network nodes or parameters, and the network 
attachment procedures; for example, the beacon scanning or New Access 
Router (NAR) discovery based on [Access Point Identifier, Access 
Router-info (AP-ID, AR-info)] tuples specified in RFC 4260 can not be 
directly applied to 3G CDMA networks. This document therefore 
specifies how Mobile IPv6 fast handovers can be applied in the 3G 
CDMA networks. 
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2's 


Requirements Notation 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [1]. 


Terminology 
This document refers to [3] for Mobile IPv6 fast handover 


terminology. Terms that first appear in this document are defined 
below: 


Access Network Identifier (ANID): An identifier that is used by the 
Packet Data Serving Node (PDSN) to determine whether the MN is 
being handed off from the access network that was not previously 
using this PDSN. Anytime the MN crosses into a new region, which 
is defined by the ANID, it must re-register with that access 
network. The ANID is further composed of the System ID (SID), 
Network ID (NID), and Packet Zone ID (PZID) and these values are 
administered by the operator. The lengths of the SID, NID, and 
PZID are 2 octets, 2 octets, and 1 octet, respectively. Thus, 
that of the ANID occupies 5 octets [11]. 


Forward Pilot Channel: A portion of the Forward Channel that carries 
the pilot. The Forward Channel is a portion of the physical layer 
channels transmitted from the 3G CDMA access network to the MN. 
Further, several sets of pilots (e.g., the active set or neighbor 
set) are defined to determine when and where to handover. 


Home Link Prefix (HLP): The prefix address assigned to the home link 
where the MN should send the binding update message. This is also 
called Home Network Prefix (HNP) and one of the bootstrap 
parameters for the MN. 


International Mobile Subscriber Identity (IMSI): The IMSI is a 
string of decimal digits, up to a maximum of 15 digits, that 
identifies a unique mobile terminal or mobile subscriber 
internationally. The IMSI consists of three fields: the Mobile 
Country Code (MCC), the Mobile Network Code (MNC), and the Mobile 
Subscriber Identification Number (MSIN). An example of the IMSI 
is "440701234567890", where "440" is the MCC, "70" is the MNC, and 
"1234567890" is the MSIN. The IMSI conforms to the ITU-T E.212 
numbering standard [6]. In this specification, IMSI is an ASCII 
string that consists of not more than 15 decimal digits (ASCII 
values between 30 and 39 hexadecimal), one character per IMSI 
digit. The above example would therefore be encoded as "34 34 30 
37 30 31 32 33 34 35 36 37 38 39 30" in hexadecimal notation. 


Yokota & Dommety Informational [Page 3] 


RFC 5271 3G CDMA Fast Handover June 2008 


Mobile Identity (MN ID): An identifier of the Mobile Node that is 
used by the access network. The value (e.g., IMSI) is unique 
within the operator’s network. 


Packet Data Serving Node (PDSN): An entity that routes MN originated 
or MN terminated packet data traffic. A PDSN establishes, 
maintains, and terminates link-layer sessions to MNs. A PDSN is 
the access router in the visited access provider network. 


Sector Address Identifier (SectorID): A typical cell divides its 
coverage area into several sectors. In 3G CDMA systems, each 
sector uses a different PN (Pseudo Noise) code offset and is 
associated with SectorID. The SectorID is 128 bits long and can 
be represented in the IPv6 address format [8]. 


4. Network Reference Model for Mobile IPv6 over 3G CDMA Networks 


Figure 1 shows a simplified reference model of the Mobile IP enabled 
3G CDMA networks. The home agent (HA) and Authentication, 
Authorization, and Accounting (AAA) server of the mobile node (MN) 
reside in the home IP network, and the MN roams within or between the 
access provider network(s). Usually, the home IP network is not 
populated by the MNs, which are instead connected only to the access 
provider networks. Prior to the Mobile IPv6 registration, the MN 
establishes a 3G CDMA access technology specific link-layer 
connection with the access router (AR). When the MN moves from one 
AR to another, the link-layer connection is re-established, anda 
Mobile IPv6 handover is performed. Those ARs reside in either the 
same or different access provider network(s). The figure shows the 
situation, where the MN moves from the Previous Access Router (PAR) 
to the New Access Router (NAR) via the radio access network (RAN). 
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Figure 1: Reference Model for Mobile IP 


In 3G CDMA networks, pilot channels transmitted by base stations 
allow the MN to obtain a rapid and accurate C/I (carrier to 
interference) estimate. This estimate is based on measuring the 
strength of the Forward Pilot Channel or the pilot, which is 
associated with a sector of a base station (BS). The MN searches for 
the pilots and maintains those with sufficient signal strength in the 
pilot sets. The MN sends measurement results, which include the 
offsets of the PN code in use and the C/Is in the pilot sets, to 
provide the radio access network (RAN) with the estimate of sectors 
in its neighborhood. There are several triggers for the MN to send 
those estimates, e.g., when the strength of a pilot in the pilot sets 
exceeds that of the current pilot, the MN sends the estimates to the 
access network. As long as the sector to which the MN is going to 
move belongs to the same access network, the mobility within that 
access network is handled by the access-specific interfaces [10] and 
the link-layer connection between the MN and AR can be maintained 
without a re-establishment. The MN can continually search for pilots 
without disrupting the data communication and a timely handover is 
assisted by the network. If, however, the serving access network 
finds that the sector associated with the highest pilot strength 
belongs to a different AR, it attempts to close the connection with 
the MN. The MN then attempts to get a new traffic channel assigned 
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in the new access network, which is followed by establishing a new 
connection with the new AR. This could cause a noticeable 
communication disruption and lead to a serious degradation of the 
user experience. In order to minimize the service degradation, 
during the handover between ARs, an IP-level fast handover approach 
as defined in RFC 5268 needs to be involved. If the air interface 
information can be used as a trigger for the handover between access 
routers, fast and smooth handover of Mobile IPv6 can be realized in 
3G CDMA networks. The MN can continually search for pilots without 
disrupting the data communication and a timely handover is assisted 
by the network. 


To assist the handover of the MN to the new AR, various types of 
information can be considered: the pilot sets, which include the 
candidates of the target sectors or BSs, the cell information where 
the MN resides, the serving nodes in the radio access network, and 
the location of the MN, if available. To identify the access network 
that the MN moves to or from, the Access Network Identifiers (ANID) 
or the subnet information can be used [9][10]. In this document, a 
collection of such information is called "handover assist 
information". In 3G CDMA networks, the Link-Layer Address of the New 
Access Point (AP) defined in [3] may not be available. If this is 
the case, the Handover Assist Information option defined in this 
document SHOULD be used instead. 


5. Fast Handover Procedures 


There are two modes defined in [3] according to the time of sending 
the FBU (Fast Binding Update); one is called "predictive mode", where 
the MN sends the FBU and receives the FBAck (Fast Binding 
Acknowledgment) on the PAR’s (Previous Access Router’s) link and the 
other is called "reactive mode", where the MN sends the FBU from the 
NAR’s (New Access Router’s) link. In the predictive mode, the time 
and place the MN hands off must be indicated sufficiently before the 
time it actually happens. In cellular systems, since handovers are 
controlled by the network, the predictive mode is well applied. 
However, if the network is not configured to be able to identify the 
new AR, to which the MN is moving next, in a timely manner, the 
reactive mode is better applied. 


Section 2 of RFC 4907 [20] suggests architectural principles on the 
link indication and the effectiveness of the optimization. The link 
indication of this document relies on 3G CDMA networks and the 
effectiveness of the optimization is attributed to RFC 5268. The 
above principles are thus considered by the related specifications 
referenced in this document. 


Yokota & Dommety Informational [Page 6] 


RFC 5271 3G CDMA Fast Handover June 2008 


5.1. Predictive Fast Handover 


Figure 2 shows the predictive mode of MIPv6 fast handover operation. 
When the MN finds a sector or a BS whose pilot signal is sufficiently 
strong, it initiates handover according to the following sequence: 


(a) A router solicitation for proxy router advertisement is sent to 
the PAR. Handover assist information for the target 3G CDMA 
network is attached to this message. 


(b) Based on the received handover assist information, the NAR is 
determined and a proxy router advertisement (PrRtAdv) containing 
the prefix of the NAR is sent back to the MN. The MN also 
checks that the R flag is not set in the PrRtAdv message, which 
indicates the network supports the predictive fast handover mode 
(defined later). 


(c) The MN creates an NCoA (new CoA) and sends the Fast Binding 
Update (FBU) with the NCoA to the PAR, which in turn sends the 
Handover Initiate (HI) to the NAR. 


(d) The NAR sends the Handover Acknowledge (HAck) back to the PAR, 
which in turn sends the FBU acknowledgment (FBAck) to the MN. 


(e) The PAR starts forwarding packets toward the NCoA and the NAR 
captures and buffers them. 


(f) The link-layer connection associated with the PAR is closed and 
a new traffic channel is assigned in the new access network. 


(g) The MN attaches to the new access network. The attachment 
procedure is access technology specific and that for 3G CDMA 
network including the PPP transactions is described later. 


(h) The MN sends the Unsolicited Neighbor Advertisement (UNA). 
(i) The NAR starts delivering packets to the MN. 
(j) The MN sends the Binding Update (BU) to the HA to update the 


Binding Cache Entry (BCE) with the NCoA, and the HA sends back 
the Binding Acknowledgment (BA) to the MN. 
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Figure 2: MIPv6 Fast Handover Operation (Predictive Mode) 


It is assumed that the NAR can be identified by the PAR leveraging 
the handover assist information from the MN. To perform the 
predictive mode, the MN MUST send the FBU before the connection with 
the current access network is closed. If the MN fails to send the 
FBU before handover, it SHOULD fall back to the reactive mode. Even 
if the MN successfully sends the FBU, its reception by the PAR may be 
delayed for various reasons such as congestion. If the NAR receives 
the HI triggered by the delayed FBU after the reception of the UNA 
((c) comes after (h)), then the NAR SHOULD send the HAck with 
handover not accepted and behave as the reactive mode. 


In (a), Router Solicitation for Proxy Advertisement (RtSolPr) is 
supposed to include the New Access Point and the MN Link-Layer 
Address (LLA) options (Option Code=1 and 2, respectively) according 
to [3]. The New AP-LLA option MAY be replaced by the handover assist 
information option in 3G CDMA networks. As for the MN-LLA option, if 
the LLA for the MN is not available, 3G specific IDs such as IMSI[11] 
MAY be used. If this is the case, the MN ID option defined in 
Section 6.2, which can support other types of IDs and a length that 
is not necessarily multiples of 8 octets, SHOULD be used instead of 
the MN-LLA option. 
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In (b), PrRtAdv MUST include options for the IP address of the NAR, 
which may be the link-local address, and the prefix for the MN. The 
PAR SHOULD be able to identify the NAR from the handover assist 
information provided by the MN. 


Figure 3 shows the call flow for the initial attachment in the 3G 
CDMA network [12]. After the traffic channel is assigned, the MN 
first establishes a link-layer connection between itself and the 
access router. As a link-layer protocol, PPP is considered in this 
figure, and a PPP handshake is depicted as an example. After a 
link-layer connection is established, the MN registers with the HA by 
sending a Binding Update message. There are several parameters for 
using Mobile IPv6é such as the home address (HoA), the Care-of Address 
(CoA), the home agent address (HA), and the home link prefix (HLP). 
In [12], obtaining these values is called bootstrapping, and the 
bootstrapping information can be obtained during the link-layer 
establishment phase and/or the mobility binding phase [13]. 
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Figure 3: Attachment Procedure in 3G CDMA Network 


The procedure for the initial attachment is as follows: 


(g) The link-layer connection establishment and the bootstrapping 
phase. 
(g-1) The LCP (Link Control Protocol) configure-request/response 


messages are exchanged. 


(g-2) User authentication (e.g., Challenge Handshake Authentication 
Protocol (CHAP) or Password Authentication Protocol (PAP)) is 
conducted. 
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(g-3) The static bootstrapping information is conveyed from the AAA 
and stored in the NAR (target PDSN). The HoA and HLP can be 
dynamically assigned by the HA in the mobility binding phase. 
This step can be skipped in the handover case. 


(g-4) Unique interface IDs are negotiated in IPv6 Control Protocol 
(IPV6CP). 
(g-5) The MN configures its link-local address based on the obtained 


interface ID. 


(g-6) A router advertisement containing the prefix is received by 
the MN. 


(g-7) The MN configures its CoA based on the obtained prefix. 


(g-8) DHCPv6 is used to obtain the static bootstrap information 
(e.g., the HA address). This step is performed in the initial 
attachment and can be skipped once the MN obtains those 
parameters. 


(g-9) The MN installs the bootstrap information for further 
procedures (e.g., the mobility binding). 


As is shown in Figure 3, it takes a considerable amount of time to 
establish a link-layer connection and almost all of the above 
sequences run every time the MN attaches to a new access network. It 
is therefore beneficial if packets in transit to the MN are saved not 
only during the time period when the MN switches to the new radio 
channel but also during the time period when the MN establishes the 
link-layer connection. 


There are several ways to configure a unique IP address for the MN. 
If a globally unique prefix is assigned per link as introduced in 
[12], the MN can use any interface ID except that of the other peer 
(the AR to which the MN is attached) to create a unique IP address. 
If this is the case, however, the PAR cannot provide the MN with a 
correct prefix for the new network in the PrRtAdv since such a prefix 
is selected by the NAR and provided in the router advertisement. The 
MN therefore configures a temporary NCoA with the prefix provided by 
the PAR and the correct NCoA MUST be assigned by the NAR. Therefore, 
in 3G CDMA network, the PAR MUST send the HI with the S flag set when 
it receives the FBU from the MN at step (c) in Figure 2. 
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The UNA is supposed to include the MN-LLA [3], but the point-to-point 
link-layer connection may be able to uniquely identify the MN. The 
most required information by the UNA is the NCoA to check if there is 
a corresponding buffer. Therefore, in (h), the function of the UNA 
can be realized in several ways: 


o Since the establishment of the link-layer connection in (g) 
indicates readiness of data communication on the MN side, the NAR 
immediately checks if there is a buffer that has packets destined 
for the NCoA, which was configured at steps (c) - (d), and starts 
delivering, if any (substitution of UNA). 


o The MN sends the UNA as defined in [3]. Instead of the MN-LLA in 
the LLA option, the MN ID MAY be included in the MN ID option 
(standard implementation of UNA). 


The primary benefit of the predictive fast handover mode is that the 
packets destined for the MN can be buffered at the NAR, and packet 
loss due to handover will be much lower than that of the normal MIPv6 
operation. Regarding the bootstrapping, the following benefit can be 
obtained, too: 


o Since the NCoA can be configured via the fast handover procedures, 
a router advertisement is not required. 


Therefore, the procedures (g-4) to (g-7) can be skipped from the 
standard MIPv6 operation in Figure 3. 


5.2. Reactive Fast Handover 


When the network does not support the predictive fast handover mode, 


the reactive fast handover is applied. In this document, a new flag 
is defined in PrRtAdv to inform the MN about the capability of the 
network (see Section 6.4). To minimize packet loss in this 


situation, the PAR instead of the NAR can buffer packets for the MN 
until the MN regains connectivity with the NAR. The NAR obtains the 
information of the PAR from the MN on the NAR’s link and receives 
packets buffered at the PAR. In this case, the PAR does not need to 
know the IP address of the NAR or the NCoA and just waits for the NAR 
to contact the PAR. However, since the PAR needs to know when to 
buffer packets for the MN, the PAR obtains the timing of buffering 
from the MN via the FBU or the lower-layer signaling, e.g., an 
indication of the release of the connection with the MN. Details of 
the procedure are as follows: 


(a) A router solicitation for proxy router advertisement MAY be sent 
to the PAR. 
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(b) The proxy router advertisement MAY be sent to the MN. If the 
information on the NAR is not available by the PAR, "0::0" MUST 
be used for the options related to the NAR (e.g., IP address of 
the NAR). 


(c) The MN sends the FBU or the access network indicates the close 
of the connection with the MN by the lower-layer signaling. If 
the MN cannot formulate the NCoA, "0::0", MUST be used for the 
NCoA in the FBU. If the B flag is set in the FBU, the PAR 
SHOULD start buffering packets destined for the PCoA. 


(d) The link-layer connection associated with the PAR is closed and 
a new traffic channel is assigned in the new access network. 


(e) The MN attaches to the new access network. This part is the 
same as described in Section 5.1 and illustrated in Figure 3. 


(£) The MN sends the UNA to the NAR. 


(g) The MN sends the Fast Binding Update (FBU) to the PAR via the 
NAR. 


(h) The NAR forwards the FBU from the MN to the PAR. 


(i) The PAR sends the Handover Initiate (HI) to the NAR with the 
Code set to 1. 


(j) The NAR sends the Handover Acknowledge (HAck) back to the PAR. 
(k) The PAR sends the FBAck to the NAR. 


(1) If the PAR is buffering packets destined for the PCoA, it starts 
forwarding them as well as newly arriving ones to the NAR. 


(m) The NAR delivers the packets to the MN. 


(n) The MN sends the BU to the HA to update the BCE with the NCoA 
and the HA sends back the BA to the MN. 
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Figure 4: MIPv6 Fast Handover Operation (Reactive Mode) 


To indicate the PAR to buffer packets destined for the PCoA, in step 
(c), a new flag ’B’ is defined in the FBU. When the PAR receives the 
FBU with this flag set, it SHOULD buffer packets for the MN. The PAR 
MAY also start buffering packets for the MN based on lower layer 
signal during handover. Since the packets are buffered at the PAR in 
this scenario, the UNA, which is received and processed by the NAR, 
can not be used to trigger to forward the buffered packets at the 
PAR. In Figure 4, the HAck from the NAR is used as the trigger for 
the forwarding of any buffered packets. 


The handover indication from the lower layer of 3G CDMA system is 


reasonably reliable by the periodical reports from the MN; however, 
there are several situations where the target link is not available 
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5. 


6. 


6. 


3. 


1 


after the handover (step (d)) and the MN comes back to the PAR, or 
the MN is not able to move to the target link for some reason after 
the connection was closed. If this is the case, the attachment 
procedure is performed on the previous link. The packets buffered at 
the PAR SHOULD be delivered to the MN after the connection is 
re-established. 


Considerations on the Link Indications 


This section discusses if the link indications assumed in this 
document meet the principles defined in Section 2 of RFC 4907[20], 
which suggests 11 architectural principles on the link indication and 
the effectiveness of the optimization. This document relies on the 
3G CDMA network regarding the link indication, which is precisely 
specified by 3GPP2. Therefore, principles (1) to (5), (7), (8), and 
(11), that is, "Model Validation", "Clear Definition", "Robustness", 
"Recovery from Invalid Indications", "Congestion Control", 
"Interoperability", "Race Condition", and "Transport of Link 
Indications" are considered by those specs. Principle (6) 
"Effectiveness" mentions the effectiveness of the optimization. This 
document bases its effectiveness on RFC 5268. Therefore, this 
principle is dealt by that RFC. Principle (9) "Metric Consistency" 
mentions inconsistencies between link and routing layer metrics. The 
spec of this document does not change the routing metrics and 
multi-homing is not considered. Finally, principle (10) "Layer 
Compression", mentions an overhead reduction scheme and 
interoperability. This document does not deal with overhead 
reduction and therefore this principle does not apply. 


Message Format 

Handover Assist Information Option 
If the lower layer information of the new point of attachment is not 
represented as the link-layer address, the following option SHOULD be 


used. The primary purpose of this option is to convey the handover 
assist information described in Section 4. 


0 1 2 3 

On 12. 3) 435 OP 87 90: P22) Bis 36 TB 9 OT, 2.3) A627 8 908 E 
Hato to bata tatatatito toto ta tatatatatitoto ta tatatatititetototetatat 
| Type | Length | Option-Code | HAI-Length | 
foto to tot atatatitototo toto tatatatitotitae ta tatatatititotototetatat 
| HAI-Value... 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 
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Type 29 


Length The size of this option in 8 octets including the 
Type, Length, Option-Code, and HAI-Length (Handover 
Assist Information-Length) fields. 


Option-Code 
1: Access Network Identifier (AN ID) 
2: Sector ID 


HAI-Length The size of the HAI-Value field in octets. 
HAI-Value The value specified by the Option-Code. 


If those that received this message do not support this option, they 
SHOULD treat this option as opaque and MUST NOT drop it. 


Option-Code indicates the particular type of handover assist 
information. Currently, two types of information are defined to 
assist the discovery of the NAR (see Section 3). 


Depending on the size of the HAI-Value field, appropriate padding 
MUST be used to ensure that the entire option size is a multiple of 8 
octets. The HAI-Length is used to disambiguate the size of the 
HAI-Value. 


The handover assist information MAY replace the New Access Point 
Link-Layer Address in 3G CDMA networks. 


6.2. Mobile Node Identifier Option 


This option is used to transfer the Identifier of the MN, which is 
not its link-layer address. 


0 1 2 3 
01.2.3.4°9.6 7 8.90.1 2°34 5 6.°7°8.90 1.2 3° 4°50 6 7-8. 9-0 1 
4+--------------- 4+--------------- +--------------- +--------------- + 
| Type | Length | Option-Code | MN ID-Length | 
+-------------------- ---- - 5 5 5 5 + 
| MN ID 
+ ek an i a le a ns ka st le a ht ag el es 
Type 30 
Length The size of this option is in 8 octets including the 


Type, Length, and Option-Code. 
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Option-Code 
1: NAI [4] 
2: IMSI (See 


MN ID-Length The length of 
MN ID MN ID value 
The MN ID MAY replace the MN 
6.3. New Flag Extension to FBU 
The MN MUST send the FBU to 
set in the previous network 
destined for the PCoA. The 


remains the same as defined 
and (P) flags as specified i 


-+-+-+-+-+-+-+-+-+-+-+-+-+- 
A|H|L|K|M|R|P|B| Reserved 
+-+-+-+-+-+-+-+-+-+-+-+- 


Mob 


+-+-+-+-+-+-+-+-+-+-+-+-+-+- 


B flag: If the ’B’ fl 
the packets d 
Section 5.2. 


Section 3) 


the MN ID in octets. 


Link-Layer Address in 3G CDMA networks. 
Message 


the PAR with the following new (B) flag 
to indicate the PAR to buffer packets 
rest of the Binding Update message format 
in [2] and with the additional (M), (R), 
n [14], [15], and [16], respectively. 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Sequence # | 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Lifetime 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| 


ility options 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


ag is set, the PAR SHOULD start buffering 
estined for the MN as specified in 


6.4. New Flag Extension to PrRtAdv Message 


A new flag ’R’ is defined in 


the PrRtAdv to inform the MN about the 


fast handover mode that the network supports. 


0 al 
0123456789012 3 


Type | Code 


Options ... 
—+-+-4+-+4+-+-4+-+4+-+-4+-+-4- 


+—+—4+—+ 


2 3 
4.9 67 8 9-0:1.2:3-4 5 6 7-8 .9 OL 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


| Checksum | 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++H 
Subtype |R| Reserved | Identifier 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++HH 
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7. 


R flag: If the ’R’ flag is set, the network supports only the 
reactive handover mode. Otherwise, the network 
supports both the predictive and reactive fast 
handover mode. 


Security Considerations 


The security considerations for Mobile IPv6 fast handover are 
described in [3]. When a 3G CDMA network is considered, it can be 
assumed that the PAR and the NAR have a trust relationship and the 
links between them and those between the ARs and the MN are secured. 
The MN is authenticated every time it attaches to the new link; 
therefore, the AR can securely identify the MN. Depending on the 
operator’s policy, however, SEcure Neighbor Discovery (SEND) [18] and 
the shared handover key defined in [17] can also be applied. 


IANA Considerations 


This document defines two new IPv6 Neighbor Discovery options that 
have been assigned from the same space as the IPv6 Neighbor Discovery 
Options defined in [19]. 


29: Handover Assist Information Option (Section 6.1) 

30: Mobile Node Identifier Option (Section 6.2) 
This document creates two new registries for the Option-Code field in 
the Handover Assist Information Option and that in the Mobile Node 
Identifier Option. The values for the Option-Code must be within the 
range 0-255. New values for both registries can be allocated by 


Standards Action or IESG approval [5]. 


The Option-Code values that have been assigned by IANA are as 
follows: 


Option-Code for Handover Assist Information Option 


Value Description Reference 
(0 Reserved 
1 ANID Section 6.1 
2 Sector ID Section 6.1 
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Option-Code for Mobile Node Identifier Option 


Value Description Reference 
0 Reserved 
1 NAI Section 6.2 
2 IMSI Section 6.2 
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